ShowTable of Contents
Introduction
Lotus Notes and Domino provide the benefit of working “locally,” using local replicas of Notes applications/databases. The main benefit---and the original idea behind the local-replica mode---is to allow users to work while offline or when connected via slow networks (dialup, reduced bandwidth, etc.). Users can do their work, reply to mail messages, access applications, etc., and then connect and replicate, simply and painlessly.
However, most Lotus Notes users today can connect via the Internet, Wireless Cards, etc., and most of these ISPs provide excellent speeds, which begs the question: Is it still a good idea to deploy local mail file replicas, and what are the benefits, considerations, and best practices for doing so?
Over the years, it's been common for companies to debate whether to deploy local replicas vs. server replicas for their employees, even if they are working on site when the servers and users are all on the same LAN.
Most organizations have based their decision on technical needs, security, user training, and the level of support they can provide (since they now have an additional configuration to support); however, the debate continues for some others.
So, the purpose of this article is to clarify why---or if---local replicas are a good option for your environment and how you can deploy this option.
NOTE: For more information on how local replicas work, refer to the Lotus Notes and Domino Administration Help database that ships with every Admin & Server licensed software (help\adminxx.nsf, where xx stands for the release number of Lotus Domino software) and to the developerWorks® Lotus article, “
Understanding and implementing local mail replicas for IBM Lotus Notes.”
Also, you may want to review the Lotus Notes 8.5 Product Documentation topic, “
Using Notes Offline.”
Server replica versus local replicas and what's best for your organization
Aside from the performance benefits, deploying local replicas should represent no changes to how your users interact with their email. However, as with making any change in a production environment, local replicas should be fully evaluated and understood, to make sure there no surprises down the road.
There are multiple advantages and considerations that must be evaluated before making a decision. To understand more about these factors, let's start with the main purpose of email, that is, to send and receive messages.
Looking at this scenario from the user's perspective, it should be as simple as “I click Send and the messages goes out. If I receive messages, they show up in my Inbox”. Properly configured scenarios work as follows:
Server replica
- When a user sends a message, it goes out immediately
- When a user receives a new message, it shows up in the Inbox immediately
Local replica
- When a user sends a message, it goes out immediately
- When a user receives a message, the message shows up in the Inbox approximately 60 seconds after it's received on the server
So, the only difference is that, for the local-replica setup, there's a 60-second delay when receiving new messages. As we demonstrate below, however, this delay is a small price to pay when compared with all the performance gains, the savings in resources' usage, and the high-availability benefits that the organization and users can realize by switching to local replicas.
After many years of working with multiple Lotus Notes and Domino environments, we have found that organizations should always base their evaluation on these key factors, which represent the vital points of any IT Infrastructure.
Table 1 shows how these factors, and many others are affected, and serves as a handy “cheat sheet“ to help organizations to decide which option to deploy.
Table 1. Effects of using local replicas on your IT environment
Parameter | Advantage | Consideration |
Infrastructure |
Server workload | Will be reduced | - |
Network utilization | Will be reduced | - |
High availability | Users will not notice if servers are down, especially in a clustered environment. | - |
Server consolidation | If less resources are needed, server consolidation could be considered. | - |
Security | - | Corporate Policies might prohibit having confidential data on users' machines. |
Initial replication / Plan and deploy | - | Extra considerations when creating the replica for the first time for remote users. |
Users |
Performance | All mail operations will be faster since they are performed locally. | - |
Inbox and folder load times | Inboxes and folders with large number of documents will load faster. | - |
Offline access | Full access to the mail file, even if there's no access to the server. | - |
Full text index and searches | Databases can be fully indexed. Searches will be performed locally and will be faster. | - |
Local Mail.box control | If Message Recall is not deployed and users are working offline, users can open the Mail.box and delete messages that haven't been sent to the server. | - |
Receipt time for new messages | - | By having the parameter ReplicateOnNewMail=1, users will see new messages up to 60 seconds after messages was received by the server. |
Support |
Troubleshooting | - | IT Support needs to be trained to handle and configure replication issues. |
Maintenance tasks | - | Database maintenance should be performed on users' machines. |
User machine resources | - | Users' machines might need more disk space. |
Let's now discuss these advantages and considerations in more detail.
Advantages of the local replica
The following are the advantages of using a local replica:
- Server workload. The server requires less resources since all user operations are performed on the client.
- Server consolidations. If all or a majority of users access their mail files via local replicas, server workload will be reduced so that more users can share the same server, meaning less administration and less costs.
- Inbox's load time. A major benefit applies to all users who like to have all messages in the Inbox. Opening the Inbox is the most “expensive” operation for the mail client so, if you move the operation to the client, load time will improve greatly since there's no need to use the server or network.
Although the user will notice a difference when opening the Inbox, keep in mind that the server must still process the large Inbox on the server replica.
- High availability and clustering. Having a local replica means you don’t care what server with which you are replicating; if one server goes down or is busy, the Notes client will replicate against the next-most-available server. You'll neither know about it nor need to be redirected to the replica on the other server.
- Offline access. Access to local replicas means 24x7 availability; if the server goes down, or you're on an airplane, or the network/Internet is down, you can still access your local replica.
Also, by deploying Directory Catalog to users' machines, you'll have a reduced version of the Company Directory, which can be used while offline. Moreover, for large companies, users won’t need to wait until the Address Book Dialog containing thousand of names loads.
- Performance/speed. Working via the local replica means that all transactions are performed locally (except for replication), requiring only minimum access to the server. This provides a huge benefit to environments that have heavy network usage, heavily loaded servers, or may be experiencing network issues.
- Network improvements. Having users work on local replicas improves not only their Notes mail experience but also may help other applications that relay on a healthy network or that require a lot of bandwidth.
- Local Mail.box control. With local replicas, users have full control of their local Mail.box. For example, if they send a message by mistake, they're able to recall it by navigating to their local Mail.box and deleting the message before it is replicated to the Domino server.
This can have the similar advantage of having the Message Recall functionality. Note, however, that Message Recall works only when both the sender and recipient are Domino mail users, and the message was sent using NRPC.
- Full text index. Some organizations don’t allow full text indexes (exact searches) due to performance or space issues. However, if you have a local replica, you can create your own full text index (and the Notes Administrator may thank you for not having to worry about those anymore).
Considerations for the local replica
The considerations and their solutions are as follows:
- Additional support/configuration. Additional Help Desk / Deskside Support may be required to handle local-replica issues such as replication delays, corruption issues, or bad configurations. Also, configuring the Notes client to work with a local replica requires some extra steps.
Solution: Policies not only let you control multiple clients’ settings, such as those for mail and security, but also allow you to control the use of local replicas. (See Section 4, “Controlling local replicas using policies,” below for more information.)
- Security. Security is always a concern when data is stored on PCs or laptops, especially if they leave the company facilities on a regular basis. When users have local replicas of their mail file or their company’s directory on their machines, all data being protected on the server (physically and digitally) is likewise stored on a user’s laptop that can be lost or stolen.
Solution: Lotus Notes provides three levels of encryption for local replicas. This encryption is based on the password-protected Notes ID file. Encryption for local replicas can be forced via policies, which can also be used to increase the complexity of passwords and even to force users to change password on a regular basis.
- Less likely to have scheduled maintenance. Since mail files are stored on users’ machines, this sometimes means---especially for users working remotely---they'll have no access to their computers if the database is corrupted, needs to be compacted, etc.
Solution: When the Compact, Updall, or Fixup task needs to be performed on a local replica, some companies have developed batch files to send to users that, when executed, will perform these tasks on all or specific databases on the Notes client.
Other companies use Microsoft® Windows® Scheduled Tasks to call specific programs on a regular basis. Since these models require the user (or the program) to enter the Notes ID password, we prefer to use Program documents in the Local Address Book (see Section 5, “Running scheduled maintenance tasks on the Notes client,” below.)
- Delay. Some users and organizations might think that they need to replicate manually every minute in order to receive the newest messages.
Solution: Local replicas can be configured to send messages immediately after the user clicks Send. They can also be configured to receive new messages every 60 seconds. Refer to Section 3, "Real-time synchronization when using local replicas,” below for more information.
- Additional resources provided to users' machines. Because users' laptops and desktops require a few extra local databases, such as extended Directory Catalog to do name lookups in the offline mode, their machines require higher disk space and memory compared with those who use server-based mail files.
Solution: There is always a bit of confusion around this topic since most people think that, now that they have a local replica, they need more resources. However, technically, it's sufficient to have the
Detailed system requirements for Lotus Notes recommended by IBM.
NOTE: Since a local replica database can be several gigabytes, just make sure there is enough space to store it. Also–and very important–make sure the local disk is healthy and fast enough to support the extra I/O.
- Initial replication / Plan and deploy. When planning a local replica deployment, you must take extra considerations for remote users. Mail files can be multiple gigabytes in size, and the creation of the replica must be carefully studied so as not to affect network resources.
Solution: There are two common approaches you can use when deploying local replicas to remote users:
a) Send an automated CD/DVD: Your IT department can create a CD/DVD with the mail file to be replicated (and additional databases, if desired and if space is available). You can instruct users to execute a batch file (let's say, MakeNotesFaster.bat) that will move the mail file from the CD/DVD to the Notes Data folder. (This method is also used when upgrading Notes Clients or installing Fix Packs.)
b) Two-phased deployment: The most important factor to consider when deploying local replicas to remote users is bandwidth. Obviously, organizations don't want to replicate big files during business hours and affect other applications using the same connection to the main office or data centers.
As a workaround, you can create two Desktop Policies, Local Replica Phase1 and Local Replica Phase2. The Phase1 policy only asks the Lotus Notes Client to create the local replica and will replicate only after business hours, but all settings still map to the server as the place to go for mail. After users confirm that the full replica of their mail file has been received, they move to the Phase 2 Policy, which changes all settings to use the local replica for mail.
In Notes 8.5.2, when your Domino administrator sets the creation of managed replica for you via a Policy, the Notes Client creates a local mail replica and marks it as a managed replica. For more information, refer to the Notes wiki article, “
Managed replicas explained.”
Real-time synchronization when using local replicas
When some organizations think about local replicas, they think about delays or no real-time access to their mail messages. However, by using the following features you can guarantee that new messages will be received roughly 60 seconds after the server replica gets the messages, and that messages sent to other users or to the Internet will be sent immediately.
Asynchronous mail replication
Asynchronous replication is one of the most important configuration settings when deploying local replicas. When this feature is enabled, it checks for new messages every 60 seconds (by default), and if there is at least one new message on the server, it triggers a replication task for the mail file (other applications in the Replicator Page are replicated on the next scheduled replication).
To enable asynchronous replication:
1. Add POLL_REMOTE_MAILFILE=1 to the client's Notes.ini file.
2. In the Notes Mail Preferences settings, enable and set “Check for new mail” to 1 minute (see figure 1).
Figure 1. Sending and Receiving Preferences window
3. In the Notes client, select File > Preferences > Locations > Edit, and select the Mail tab (see figure 2). In the Edit Location window, set the:
- Mail file location field to “Local”
- Mail Addressing field to “Local then Server” or “Server then Local”
Figure 2. Mail tab of the Edit Location window
Note that all these settings can be deployed and controlled via Policies. Refer to Section 4 below to understand how to achieve this configuration. Also, an active session is required with the user's Home mail server.
Controlling when messages leave the local Mailbox database
Another big concern for users is having to wait until the next replication to make sure a message is sent when they click Send. This may be hard to understand for some, or simply not desirable; however, by using Desktop policies, you can control when messages are sent when using local replicas.
Desktop policies let you modify additional settings on the Location document that are not included as options in the Desktop Settings document.
To do this, within your Notes client, again select File > Preferences > Locations > Edit, and select the Mail tab (recall figure 2). At the bottom of the window, use the “Transfer outgoing mail if:” field to set the maximum number of messages that must be in the local Mail.box before being sent to the server.
For Notes and Domino versions 8.0.2 and later, refer to the
Domino Policies Demystified blog for more information about updating specific Location document fields.
To update this value in the Location document in Notes and Domino 8.0.1 or earlier, follow the instructions in IBM Support Technote #1196837, “
Using a Desktop Policy to set notes.ini and Location parameters.“
Setting mail files to use high-priority replication
Scheduled replication is still recommended to maintain synchronization between both replicas (local and server), and when users move messages to folders, read email messages (that is, update unread marks), create folders, etc.
To maintain a minimum amount of data to be replicated, you can set high-priority replication for the mail file. This configuration mainly applies when users have multiple local replicas of different applications.
Currently, Policies can be used to create mail files’ local replicas but
not to set them to use the replication schedule for high-priority databases. However, with a little bit of coding you can change this. The example code in listing 1 shows how to set a database to use high-priority replication. You can adapt the code as needed.
Listing 1. Code to set high-priority replication
Dim db As NotesDatabase
Dim replication As NotesReplication
‘... your code here
Set db = ‘<set the NotesDatabase Object>
Set replication = db.ReplicationInfo
replication.priority = DB_REPLICATION_PRIORITY_HIGH
Call replication.Save()
‘... your code here
Also, as a best practice, instead of running this code every time you create new mail files, you can just change the setting on the Mail Template(s), so that all databases created from that template will inherit the setting.
To do this, open the mail file, select File > Replication > Options for this Application, select Other, and then change the “Set scheduled replication priority for this replica” field to High (see figure 3).
Figure 3. Replication Options window
Controlling local replicas using Policies
Since local replicas may need some extra configuration for the Notes client, it's a best practice to use Policies, which let you deploy all required configurations without touching the end users' PCs. Policies are administered from the server, allowing you to have the same or controlled configurations across the environment.
Having only one policy for an entire organization is probably not the best option in most cases. It is, however, a good idea to identify the common settings that can either be used via multiple policies (that is, use the same Desktop or Setup Settings documents on multiple policies) or that have the same configuration across multiple Settings documents. In this way, you'll have a standard/easier environment to troubleshoot.
Tables 2—5 and the corresponding figures 4—7 show some common practices when configuring Desktop or Setup policies to control local replicas.
NOTE: In the tables below, an asterisk “*” means the setting is available only on Setup policies, the plus “+” sign means it is available on Desktop policies, and “+*” means it is available on both policies' settings.
Table 2. Settings in the Applications tab of Desktop Settings policy
Applications (Desktop) or *Databases (Setup) |
Setting | Value | Description |
| +*Mobile directory catalogs | Database link to the mobile directory catalog | This is a reduced version of the Domino Directory that improves performance when doing name lookups and makes the Directory available, even when working offline. |
Figure 4. Applications tab of Desktop Settings policy
Table 3. Settings in the Mail tab of Desktop Settings Policy in pre-8.5.2 Notes versions
Mail (Desktop) or *Basics (Setup) |
Setting | Value | Description |
| +*Local mail file | Enabled; Create local mail file replica | After a user receives a policy with this setting, the Notes Client pulls a replica of the mail file specified in the Person document of the current user. |
| +Mail file location | Local | Modifies the current Location document by setting mail bookmarks (default links) to access the local mail file. |
Table 3a. Settings in the Mail tab of Desktop settings Policy in 8.5.2
Mail (Desktop) or *Basics (Setup) |
Setting | Value | Description |
| +*Local mail file | Create Managed Replica or convert local replica to managed replicas | After a user receives a policy with this setting, and if no replica exists, then the Notes Client creates a local replica and marks it as a managed replica.
If a local replica exists, then it converts the local replica to managed replicas. |
| +Mail file location | Local | Modifies the current Location document by setting mail bookmarks (default links) to access the local mail file. |
Figure 5. Mail tab of Desktop Settings policy in pre-8.5.2 Notes versions
Figure 5a. Mail tab of Desktop Settings Policy in Notes 8.5.2
Table 4. Settings in the Preferences > Mail tab of Desktop Settings policy
+Preferences\Mail (Desktop) or *Preferences\Mail and News (Setup) |
Setting | Value | Description |
| +*Check for new mail | Enabled | The Lotus Notes client checks the local replica for new messages every X minutes and notifies the user. |
| +*Mail checking interval | 1 | The Lotus Notes Client will check for new messages every 1 minute. |
| +*Play a sound | Enable | Notifies the user of new mail by playing a sound. (Note that you can also use “Show a popup,” but most users find this annoying.) |
| +*Automatically refresh Inbox | Enable | Refreshes the Inbox and shows new messages without manual refresh (clicking the refresh icon). |
| +*Show an icon in System Tray | Enable | Shows a small icon (envelope) in the Windows System Tray |
Figure 6. Preferences > Mail tab of Desktop Settings policy
Table 5. Settings for Preferences > Replication tab of Desktop Settings policy
+Preferences\Mail (Desktop) or *Preferences\Mail and News (Setup) |
Setting | Value | Description |
| +* Amount of the document that Notes should replicate | Enable | Lotus Notes replicates the entire document and any attachment(s) in it. |
| + Create a full text index for faster searching | Enable | Creates/updates the full text index after replication if any modification occurs. |
| * Create replicas ready for searching | Enable | Indexes the mail file immediately after the replication is completed. |
| +* Encrypt replicas | Locally encrypt | This is a must. Local replicas should be encrypted because data residing on local hard drive of laptop / PC has more security risks. |
| + Encrypt using | Medium | Provides the correct balance among security, strength, and fast database access. This level is probably the appropriate choice for most users. |
| +Enable replication for All locations | Yes | Enables replication on the Lotus Notes Client. |
| +Normal-priority replication: | Check mark (Enable) | Enables normal-priority replication. |
| +Replicate daily between | 12:01 AM -- 11:59 PM | Make sure you open the replication interval to 24 hrs a day. Limiting the replication to business hours can upset some users who like to work after hrs on the weekend. Plus, you don’t want to get a call at 2 AM from the CEO asking why his client is not replicating. |
| +Repeat every | 30 | This number is up to you, but make sure it's not less than 15. Remember, this is a normal-priority replication. |
| +Days of week | Sun, Mon, Tue, Wed, Thu, Fri, Sat | Make sure it runs 7 days a week, keeping in mind that some users work on Sundays. |
| +High-priority replication: | Check mark (Enable) | Since mail is the most important topic here, we want to make sure high-priority replication is enabled.
NOTE: Mail files are not set as high priority by default (Section 3.3 above explains how to set all mail files to use this feature with just a few lines of code.) |
| +Replicate daily between | 12:01 AM -- 11:59 PM | Again, make sure it runs 24 hrs a day. |
| +Repeat every | 15 | Since only a few databases are actually required to be high priority, you can set this value to 5. |
| +Days of week | Sun, Mon, Tue, Wed, Thu, Fri, Sat | Make sure it runs 7 days a week, keeping in mind that some users work on Sundays. |
| +Replicate when the user starts the client: | Enable | Most users want to start reading their new messages as soon as they start Lotus Notes. |
| +Replicate when the user shuts down the client: | Enable | It's important to ensure that all pending changes are replicated before closing the Notes Client and going on vacation. |
Figure 7. Preferences > Replication tab of Desktop Settings policy
When creating policies, the options for the “How to apply this setting” field should be set based on the desired result, as follows:
- Set value and prevent changes. Makes the most sense when you don’t want users to change any of these settings.
- Set initial value. Sets the desired value, but then users are free to change it whenever they want.
- Set value whenever modified. Sets the desired value and then, if it's changed by a user, will reset the value every time the policy is updated.
- Don’t set value. Make sure this option is selected for all the settings you don’t want to control via policies.
For more information, refer to the “
Policies” topic in the Domino 8.5 Administrator Product Documentation.
Running scheduled maintenance tasks on the Notes client
Just like databases on a server, local replicas must be maintained to ensure good performance. There are no out-of-the-box features available to run scheduled maintenance tasks but, with a little effort, you can make it work.
The Personal Address Book (PAB, or “Your Contacts on Local”) database has a view named “($Programs)” that can be used to administer and run scheduled programs via the Notes client (see figure 8). To see this view, using the Notes Designer:
1. Open the Pubnames.ntf database and select Forms.
2. Copy the “Server\Program” form and paste it into the PAB.
3. Using your Notes client, open the PAB.
4. Press Ctrl + Shift, and select View > Go To > ($Programs). Click OK.
Figure 8. PAB ($Programs) view
5. Click Create > Server > Program. You'll see warnings stating “Cannot locate field definition for Field $HTMLAttributes” and “… for Field LastMod”. You can either return to the form, using the Lotus Designer, and delete the fields, or live with the warnings.
6. Now, just like in the Domino Directory, enter the required parameters (see figure 9). You can run the required task for one database, a specific folder, or for all of them (again, just like on the server).
Figure 9. Program document in the PAB
The ($Programs) view should now look similar to figure 10.
Figure 10. $Programs view with added tasks
At this point you can use any propagation method you want to deploy this configuration to all your local-replica users. Table 6 lists some common practices to create/propagate these documents.
Table 6. Deployment options
Deploy method | Executed when |
1. Using a Database script that creates the Program documents if they don't exist in the local Names.nsf database. | Database is opened |
2. Send an email with the code embedded in a button | User clicks the button |
3. If users are Roaming Users or have a server replica of their PABs, you can control the creation and maintenance of these documents via agents or a customized interface. | When client replicates |
Note that the fields below in the Program form must be generated based on the user.
- Command line: If running maintenance tasks on user’s mail file.
- Server to run on: This parameter defines the user’s client. If you are logged in to Lotus Notes with a user not defined in this value, the scheduled task will not run.
To check whether the local Program document works, open the Notes client’s Log.nsf database and look for the task that was requested to run. You should see something like the Miscellaneous Events window shown in figure 11.
Figure 11. Confirmation that the local compact process was successful
DAOS and local replicas
If you're running Domino 8.5.x and the Domino Attachment and Object Service (DAOS), keep in mind that your server replica will have a physical size different from the logical size, in contrast to the local replica, for which the physical size and logical size are the same.
Since DAOS is a server-only feature, when a mail file is replicated locally, all attachments will be added back to the mail file. For example, suppose John Doe’s server mail file is 8GB (physical size) and 2GB (logical size), whereas the local-replica size (both physical and logical) is 8GB. This means that the server can be much more efficient than the client because it's opening a 2GB file rather than an 8GB file.
In this scenario, the user’s CPU, memory, and disk speed/health will define which option is better. Make sure enough tests are performed to determine whether a local replica will actually improve speed and the end user's experience.
Managed Replicas in Lotus Domino 8.5.2
Starting with Lotus Domino 8.5.2, IBM introduced a new feature called “Managed Replicas” that automates all steps described above in Sections 3.1, 3.2, and 6.
Note that Managed Replicas still require an open session against the server and a scheduled replication, to maintain both replicas – Server and Local/Managed – fully synchronized. Managed Replicas can be enabled via Desktop Policies or Notes.ini settings.
To enable Managed Replicas via Desktop Policies, enable the settings as shown in table 7 (repeated from table 3 for convenience).
Table 7. Settings in the Mail tab of Desktop settings Policy in Notes 8.5.2
Mail (Desktop) or *Basics (Setup) |
Setting | Value | Description |
| +*Local mail file | Create Managed Replica or convert local replica to managed replicas | After a user receives a policy with this setting, and if no replica exists, then the Notes Client creates a local replica and marks it as a managed replica.
If a local replica exists, then it converts the local replica to managed replicas |
| +Mail file location | Server | Modifies the current Location document by setting mail bookmarks (default links) to access the local mail file. |
The main consideration when deploying Managed Replicas is that Administrators cannot control when a local replica is created since the Managed Replica feature will delete a corrupted replica and create a new one automatically. For some environments, this might be a disadvantage since remote users are probably connected via the Internet or by using a shared connection with other coworkers (if working on remote offices).
For this scenario, it is recommended to enable and apply Managed Replicas only to users working on the same LAN as the server and to users with small mail files. Another workaround is to enable Selective Replicas, which will create a subset of the mail file with the documents received in a pre-defined number of days.
For more information about Managed Replicas, refer to the IBM Support Technotes, “
Configuring managed replicas using the Desktop Settings document,” and “
Understanding Managed Replicas (Q&A, Troubleshooting, and Known Issues).”
Conclusion
To sum up the key points of this article:
- Using local replicas can benefit your environment since servers' and network’s workload is reduced, downtime is virtually eliminated, and general user experience and performance is improved. However, the local PC’s resources may define whether local replicas are the best solution for you.
- As always, tests should be performed before making changes in production environments and/or rolling out configuration changes to all users.
- If through testing you find that switching to local replicas improves performance, then they are probably for you (remember that, although local replicas may require some extra configuration, there's more benefit than “harm”---if any).
- Make sure your users know how local replicas work; specifically, they should understand that all transactions are performed locally and, based on the replication schedules and local Mail.box settings, there may be certain delays when receiving and sending mail.
Resources
Lotus Domino and Notes Product Documentation:
http://www-10.lotus.com/ldd/dominowiki.nsf/xpViewCategories.xsp?lookupName=Product%20Documentation
developerWorks article, “Understanding and implementing local mail replicas for IBM Lotus Notes:”
http://www.ibm.com/developerworks/lotus/library/local-mail-replicas/
developerWorks Lotus Notes and Domino product page:
http://www.ibm.com/developerworks/lotus/products/notesdomino/
Lotus Notes/Domino 8.5 Forum:
http://www-10.lotus.com/ldd/nd85forum.nsf
About the authors
Luis Guirigay is a Senior IT Specialist at
PSC Group, LLC focused on administration, high availability / disaster recovery, performance tuning, and high-level support. He has worked with IBM & Lotus products for more than 12 years and is an IBM Certified Administrator for Lotus Domino, Sametime®, Connections, Quickr®, and for WebSphere® Portal. He's an IBM Certified Developer in Domino and Lotus Workflow, and has extensive experience with WebSphere Application Server, DB2®, Tivoli and ILWWCM.
Luis has authored multiple IBM Redbooks® publications related to Domino, Workplace, DB2, and System i®. His speaking engagements include the Midwest Lotus User Group Conference, Chicago Lotus User Group, and multiple IBM PoT and IBM Workshops in the Midwest. He can be reached at
lguirigay@psclistens.com. You can also follow him on Twitter @lguiriga.
Shankar Venkatachalam is an IBM Software Engineer based at IBM's Pune, India, facility. He works on the Domino Crash, Core, and Performance Analysis Support team and is an IBM Certified Administrator for Lotus Domino. Using his knowledge of LotusScript, he has developed automations for Lotus Administration tasks, including (1) a single Domino database that purges dead mail from all servers in a domain, (2) a means of checking the TDP Backup logs, (3) a database to create mail-in databases at the backend, and (4) a tool/database that sends a Welcome message for all newly registered users in a domain. You can reach Shankar at
svenkat7@in.ibm.com.